1. Field of the Invention
The present invention relates, generally, to resource provisioning management (RPM) systems, and, in preferred embodiments, to third party providers of resource provisioning management services.
2. Description of Related Art
A common use of communication networks is to provide users access to network resources such as software, electronic data, or files in storage systems or databases connected to the network. As the number of users on a given network increases, there is often a need to control user access rights to resources on the network. However, as the number and type of resources available over the network increase, the difficulty in managing access rights to such resources tends to increase. Further difficulties arise where resources are in remote locations, accessible to users over a distributed network, such as the Internet.
Network environments often involve a variety of network users, where the users may be grouped or categorized by a relation or role that the user serves in the environment. For example, in an engineering or technical development company environment, users of the company's computer network may include company officers, directors, managers, engineers, technical support staff, office support staff, accounting department staff, information technology (IT) department staff, contractors, consultants, temporary employees or other relation-based or role-based groups or categories of network users. Other companies, organizations or network environments may have other relation or role-based groups of users. Each user may have a need to access certain network resources in connection with the user's relation or role. In addition, it may be desirable to restrict users with certain relations or roles from access to certain resources, for example, for security, privacy or other reasons.
Depending on the network environment, other types of resources may also be allocated to (or restricted from) users, based on the user's relation or role in the environment. For example, in the engineering or development company environment described above, users may be allocated such resources as telephones, telephone accounts, computers, Internet accounts, e-mail accounts, office equipment and supplies, laboratory or engineering equipment and supplies, or other resources, based on the user's role or relation with the company.
In many conventional businesses or organizations, specific personnel perform the function of provisioning users according to their roles. For example, an office administrator may place an order with the organization's information technology (IT) department to have a computer, telephone, voice mail, e-mail, and certain applications and databases available on the day a new user joins the organization. Individuals from the IT department would then manually set up these resources. Other office personnel may bring desks, chairs, and cabinets from storage and set up the user's office. Over the course of time, the user's relationship or roles within the organization may change, for example, as the user is transferred, promoted, demoted or terminated from the organization. As a user's relationship or role with the organization changes, the user's needs or rights to access resources may change.
The burden on the office administrator and office personnel to manually administer user access to resources in the above example is typically dependent on the size of the organization (the number of users) and the rate at which users join or leave the organization or otherwise change roles. To improve efficiency and reduce the burden on the office administrator and office personnel, some organizations have used software applications which automate or partially automate some of the tasks relating to provisioning certain, limited types of resources to users.
Role Based Access Control (RBAC) is one form of automatic provisioning that has become commercially available. RBAC provides permissions (access rights) to a user to access certain accounts (files, web pages, etc.) available over the network, based on a person's role in the organization. For example, a file or folder may be viewed only by its creator, or may be accessible to a larger group of users through an organization's network, depending on the permission rights established for that file or folder. In conventional RBAC systems, these permissions are based on a person's role within the organization.
However, modern organizations may be structured along several intersecting lines. For example, organizations may be structured according to title (presidents, vice-presidents, directors, managers, supervisors, etc.), technology (electronics, mechanical, software, etc.), project (product A, B, C, etc.), location (Irvine, N.Y., etc.) and the like. A single user may appear in several or all of these organizational structures, and thus may be in a somewhat unique overall role as compared to other users in the organization. Because this may require that many users be provisioned uniquely, many unique roles would have to be defined in the system to automate such provisioning. Furthermore, conventional RBAC only provisions “soft” resources such as accounts, applications, databases, files, Web pages, and the like, as opposed to “hard” resources such as telephones, computers, desks, and the like.
The software applications which automate or partially automate some of the tasks relating to provisioning certain, limited types of resources to users are operable on a communication network for provisioning users with resources according to established criteria. Systems employing such software applications will be generally referred to herein as RPM systems.
Although the third party service providers or managed services (collectively known as managed resources) may have user management consoles which enable a human to make changes to the managed resource, the consoles or interfaces may be incompatible with the RPM system. Because of this, software agents may be deployed as translators between the RPM system and the managed resources. The agent, in essence, replaces human intervention with automated steps that perform essentially the same function. The agent is capable of receiving a message or request from the RPM system, and translating the request to code that can interface with the Application Programming Interfaces (APIs) of the managed resource. After the managed resource performs the particular function of the request, the managed resource may pass values to the agent, which may then communicate the values back to the RPM system.
Unfortunately, the implementation of an RPM system may require resources that are cost-prohibitive for some companies or organizations. Implementation of an RPM system typically requires system servers, terminals, system software, agents and other items associated with a communications network. Expenditures for such items can be tremendous, costing anywhere from tens of thousands to hundreds of thousands of dollars. These costs may be overwhelming for companies or organizations of modest means, thereby putting acquisition and implementation of an RPM system out of reach.
Also, the implementation of an RPM system typically requires a commitment to personnel for the operation of the system. The cost required to hire and train such personnel and the costs for associated overhead may discourage some companies or organizations from implementing an RPM system altogether. Thus, without a viable alternative for RPM services, these companies and organizations cannot benefit from an RPM system.
Companies and other organizations who lack the resources for or who are otherwise discouraged from acquiring and implementing an RPM system could benefit greatly from third parties who function as providers of RPM services. Up until now, however, a system and method for providing third party RPM services has not existed. Generally, an RPM system and method has heretofore been implemented within an organization utilizing resources in an enterprise or application service provider environment.
Tremendous benefit could also be obtained by companies and other organizations utilizing third party RPM service providers if the resources being provisioned could be shared among such companies or organizations. Such sharing among affiliated companies could provide cost savings and administrative efficiency. Again, however, up until now, a mechanism for sharing resources among affiliate companies or organizations utilizing third party RPM service providers has not existed.
A need also exists for a public infrastructure generally in the RPM sector. There does not currently exist any third party RPM service provider delivering provisioning services such as identity, entitlement, policies and roles for the general public to utilize when the need for resource provisioning arises.